Method and apparatus for use in a communications network

ABSTRACT

A method and apparatus for registering a mobile node such as a User Equipment (UE) of a UMTS telecommunications network with a subsystem of the network such as an IP Multimedia Subsystem (IMS). A Policy and Charging Rules Function (PCRF) node provides policy and charging rules, and a Gateway GPRS Support Node (GGSN) enforces the rules for traffic flows. The UE sends a registration request to the GGSN, which selects a PCRF. When a Proxy Call Session Control Function (P-CSCF) receives the registration request, the P-CSCF selects a candidate PCRF and validates the selection. If the candidate PCRF is the PCRF selected by the GGSN, the registration is successful. If not, the P-CSCF may select another PCRF and repeat the validation process.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method and apparatus for use in acommunications network, for example a Universal MobileTelecommunications System having an IP Multimedia Subsystem.

2. Description of the Related Art

IP Multimedia services provide a dynamic combination of voice, video,messaging, data, etc. within the same session. By growing the number ofbasic applications and the media which it is possible to combine, thenumber of services offered to the end users will grow, and theinter-personal communication experience will be enriched. This will leadto a new generation of personalised, rich multimedia communicationservices, including so-called “combinational IP Multimedia” services.

By way of background, UMTS (Universal Mobile Telecommunications System)is a third generation wireless system designed to provide higher datarates and enhanced services to subscribers. UMTS is a successor to theGlobal System for Mobile Communications (GSM), with an importantevolutionary step between GSM and UMTS being the General Packet RadioService (GPRS). GPRS introduces packet switching into the GSM corenetwork and allows direct access to packet data networks (PDNs). Thisenables high-data rate packets switch transmissions well beyond the 64kbps limit of ISDN through the GSM call network, which is a necessityfor UMTS data transmission rates of up to 2 Mbps. UMTS is standardisedby the 3^(rd) Generation Partnership Project (3GPP) which is aconglomeration of regional standards bodies such as the EuropeanTelecommunication Standards Institute (ETSI), the Association of RadioIndustry Businesses (ARIB) and others. See 3GPP TS 23.002 for moredetails. The standardisation of UMTS has progressed in phases. The firstphase was known as Release '99. The Release '99 specifications definethe basic architecture that consists of the UMTS Terrestrial RadioAccess Network (UTRAN), Circuit Switched Core Network (CS-CN) and PacketSwitched Core Network (PS-CN). The release '99 specification offerstraditional circuit as well as packet-switched services. The next phasein the standardisation process was Release 4, adding new services to the'99 architecture. Release 5 represented a significant shift, offeringboth traditional telephony as well as packet-switched services over asingle converged packet-based network.

The UMTS Release 5 architecture added a new subsystem known as the IPMultimedia Subsystem (IMS) to the PS-CN for supporting traditionaltelephony as well as new multimedia services. IMS provides IP Multimediaservices over mobile communication networks (3GPP TS 22.228, TS 23.228,TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to7). IMS provides key features to enrich the end-user person-to-personcommunication experience through the use of standardised IMS ServiceEnablers, which facilitate new rich person-to-person (client-to-client)communication services as well as person-to-content (client-to-server)services over IP-based networks. The IMS is able to connect to bothPSTN/ISDN (Public Switched Telephone Network/Integrated Services DigitalNetwork) as well as the Internet. The IMS makes use of the SessionInitiation Protocol (SIP) to set up and control calls or sessionsbetween user terminals (or user terminals and application servers). TheSession Description Protocol (SDP), carried by SIP signalling, is usedto describe and negotiate the media components of the session. WhilstSIP was created as a user-to-user protocol, IMS allows operators andservice providers to control user access to services and to charge usersaccordingly. The 3GPP has chosen SIP for signalling between a UserEquipment (UE) and the IMS as well as between the components within theIMS.

FIG. 1 is an illustrative diagram showing a UMTS communications network200 comprising a User Equipment (UE) 204 located within a VisitedNetwork 202. The UE 204 is attached to a Serving GPRS Support Node(SGSN) 208 via a UTRAN 206, which is in turn in communication with aGateway GPRS Support Node (GGSN) 210. Within the Visited Network 202,the GGSN 210 communicates with a Proxy Call Session Control Function(P-CSCF) 212, which is the first point of contact in the visited IMSnetwork for the UE 204. The P-CSCF 212 forwards SIP registrationmessages and session establishment messages to the Home Network 214.

The first point of contact within the Home Network 214 is theInterrogating Call Session Control Function (I-CSCF) 216, which is anoptional node in the IMS architecture, whose main purpose is to querythe Home Subscriber Server (HSS) 220 to find the location of the ServingCall Session Control Function (S-CSCF) 218. The S-CSCF 218 performssession management for the IMS network, and there can be several S-CSCFsin the network. The HSS 220 is a centralised subscriber database, andhas evolved from the Home Location Register (HLR) from earlier UMTSreleases. The HSS 220 interfaces with the I-CSCF and the S-CSCF toprovide information about the location of the subscriber and thesubscriber's subscription information.

The communications network 200 further comprises an application server222, a database 224 and a mail server 226 located in the Home Network214. From the S-CSCF 218, signalling messages are passed to the intendeddestination, which may be another Release 5 IMS network 228 comprising aUE 230, or to a legacy network 232 comprising a PSTN interfaced througha Media Gateway Control Function (MGCF), or to an IP network 234.

Specific details of the operation of the UMTS communications network 200and of the various components within such a network can be found fromthe Technical Specifications for UMTS which are available fromhttp://www.3gpp.org.

Further details of the use of SIP within UMTS can be found from the 3GPPTechnical Specification TS 24.228 V5.8.0 (2004 March), but a summarywill now be provided with reference to FIG. 2, which illustratesschematically how the IMS fits into the mobile network architecture inthe case of a GPRS/PS access network (IMS can of course operate overother access networks). Call/Session Control Functions (CSCFs) operateas SIP proxies within the IMS. As mentioned above, the 3GPP architecturedefines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the firstpoint of contact within the IMS for a SIP terminal; the Serving CSCF(S-CSCF) which provides services to the user that the user is subscribedto; and the Interrogating CSCF (I-CSCF) whose role is to identify thecorrect S-CSCF and to forward to that S-CSCF a request received from aSIP terminal via a P-CSCF.

A user registers with the IMS using the specified SIP REGISTER method.This is a mechanism for attaching to the IMS and announcing to the IMSthe address at which a SIP user identity can be reached. In 3GPP, when aSIP terminal performs a registration, the IMS authenticates the user,and allocates a S-CSCF to that user from the set of available S-CSCFs.Whilst the criteria for allocating S-CSCFs is not specified by 3GPP,these may include load sharing and service requirements. It is notedthat the allocation of an S-CSCF is key to controlling (and chargingfor) user access to IMS-based services. Operators may provide amechanism for preventing direct user-to-user SIP sessions which wouldotherwise bypass the S-CSCF.

During the registration process, it is the responsibility of the I-CSCFto select an S-CSCF if a S-CSCF is not already selected. The I-CSCFreceives the required S-CSCF capabilities from the home network's HomeSubscriber Server (HSS), and selects an appropriate S-CSCF based on thereceived capabilities. [It is noted that S-CSCF allocation is alsocarried out for a user by the I-CSCF in the case where the user iscalled by another party, and the user is not currently allocated anS-CSCF.] When a registered user subsequently sends a session request tothe IMS, the P-CSCF is able to forward the request to the selectedS-CSCF based on information received from the S-CSCF during theregistration process.

Within the IMS service network, the Application Servers (ASs) are forimplementing IMS service functionality. Application Servers provideservices to end-users in an IMS system, and may be connected either asend-points over the 3GPP defined Mr interface, or “linked in” by anS-CSCF over the 3GPP defined ISC interface. In the latter case, InitialFilter Criteria (IFC) are used by an S-CSCF to determine whichApplications Servers should be “linked in” during a SIP Sessionestablishment (or indeed for the purpose of any SIP method, session ornon-session related). The IFCs are received by the S-CSCF from an HSSduring the IMS registration procedure as part of a user's User Profile.

An important function of any mobile core network is the enforcement ofservice level policies. These policies dictate, inter alia, whatparticular users may and may not do, and what they will be charged.Another policy might dictate the Quality of Service (QoS) thatparticular users will receive. Service level policies, which might bethought of as general policy statements, are enforced using detailedpolicy “rules”. A single policy may require a set of policy rules. Eachpolicy rule will comprise a first subject part identifying the packetsthat the policy rule will be applied to, and a second action part. Thesubject part may in some cases be a packet filter. Policy rules areinstalled into a node through which all traffic of the users pass orinto multiple nodes, which collectively handle all traffic of the user.

In the case of 3GPP, it is envisaged that policing and chargingfunctionality will be controlled from a so-called Policy and ChargingRules Function (PCRF) logical node, based on signalling from ApplicationFunctions (AFs) providing high level services to users. Consider forexample the IP Multimedia Subsystem (IMS) described above. When a callis set up over the IMS, the IMS Proxy Call/State Control Function(P-CSCF) acts as AF from a policy and charging point of view and informsthe PCRF of the new session. In particular, the P-CSCF sends to the PCRFa descriptor of the IP flow, and an abstract definition of the QoS toapply. The PCRF has installed into it, for each user, a policy whichdescribes how packet flows for that user are to be handled, i.e.allowed/denied services, charges, actual QoS, etc. (This may beinstalled manually into the PCRF or may be installed remotely, e.g. by auser's home network where the PCRF is located in a “visited” network.)

Considering this scenario in more detail, the AF sends to the PCRF aflow descriptor in the form of a complete or partial five-tuple vectorcontaining: (1) IP source address, (2) IP destination address, (3) anidentification of the used transport protocol (e.g., TCP or UDP), (4)source port number and (5) destination port number. The PCRF applies thepolicy to this vector to generate a set of policy rules. For example,the policy may specify the charge and QoS to be applied to a callbetween the IP addresses and port numbers contained in the vector. Theresulting rules will contain the five tuple vector as the subject partand the appropriate charging and QoS actions in the action part. ThePCRF installs the policy rules into the traffic node at which the ruleswill be enforced. If the addresses/port numbers of a packet passingthrough the enforcement node match the filter part of a rule, the actionspecified at that rule is carried out. The traffic node is referred toas the Policy Enforcement Function (PEF) and, in the case of a cellularnetwork incorporating GPRS, is usually located in a GPRS Gateway SupportNode (GGSN), or an evolution of the GGSN.

Flexible Bearer Charging (FBC) and Service Based Local Policy are twopolicy control architectures defined in 3GPP Rel-6 (TS 23.125 and TS23.207 respectively). The two architectures are being harmonised for3GPP Rel-7 into one Policy and Charging Control (PCC) architecture, inline with the evolution direction set out in TR 23.803. The policyfunctionality is distributed in the network across a number of entities:the Application Function (AF), the Policy Control and Charging RulesFunction (PCRF), and the Gateway (GW), as shown in FIG. 3 of theaccompanying drawings (from TR 23.803).

For Rel-6 policy control over Go the binding mechanism uses anAuthorization Token and one or more Flow Identifiers. An important rolefor the token is to provide address information to the GGSN (GW) forfinding the Policy Decision Function (PDF) that issued the token, thusbeing the node to contact for seeking authorization for the flowsdescribed by the Flow Identifiers. The Rel-6 Flow Based Chargingarchitecture ensures that both the Traffic Plane Function (TPF) (in theGW) and an AF, which requires information being provided to the ChargingRules Function (CRF) for the user session, contacts the same CRF. ForFlow Based Charging, the TPF contacts the CRF based on access point theUE connects to (i.e. Access Point Name, APN) and the AF contacts the CRFbased on the end user (IP) address as experienced at the AF.

The Rel-7 PCC will re-use the Rel-6 FBC TPF to CRF addressing mechanismof Flow Based Charging for the GW to PCRF addressing. As the Flow BasedCharging solves the problem of the AF finding the same CRF that the TPFcontacts, the Rel-7 AF will re-use the Rel-6 AF to CRF addressingmechanism of Flow Based Charging for the AF to PCRF addressing. It istherefore the GW that will select the PCRF to be serving the UE, and theAF will ensure that it provides its authorisations to the same servingPCRF.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention there is provided amethod of registering a mobile node of a telecommunications network to asubsystem of the network, the network having at least one node formaintaining or having access to policy and charging rules for users ofthe network and at least one node for enforcement of the policy andcharging rules to traffic flows, the method comprising receiving aregistration request message from the mobile node at a proxy node of thenetwork, selecting a candidate policy and charging rules node for themobile node, determining whether the candidate policy and charging rulesnode has already been selected by a policy and charging rulesenforcement node to serve the mobile node, and performing subsequentsteps of the registration procedure in dependence on the determination.

The network may be a Universal Mobile Telecommunications System.

The mobile node may be a User Equipment of the Universal MobileTelecommunications System.

The or each policy and charging rules node may comprise a Policy andCharging Rules Function of the Universal Mobile TelecommunicationsSystem.

The or each policy and charging rules enforcement node may comprise aGateway Node of the Universal Mobile Telecommunications System, such asa Gateway GPRS Support Node.

The proxy node may comprise an Application Function of the UniversalMobile Telecommunications System.

The proxy node may comprise a Proxy Call Session Control Function of theUniversal Mobile Telecommunications System.

The subsystem may be an IP Multimedia Subsystem.

The determining step may comprise sending a validation request from theproxy node to the candidate policy and charging rules node comprisinginformation for use by the candidate policy and charging rules node indetermining whether it has already been selected by a policy andcharging rules enforcement node to serve the mobile node, and basing thedetermination on a reply received from the candidate policy and chargingrules node.

The validation request may be sent as part of an Application Functionsession between the proxy node and the candidate policy and chargingrules node.

The information may comprise an IP address of the mobile node.

The method may comprise checking whether the IP address of the mobilenode is already stored in the candidate policy and charging rules node.

The method may comprise, if it is determined that the candidate policyand charging rules node has already been selected by a policy andcharging rules enforcement node to serve the mobile node, continuingwith steps to register the mobile node to the subsystem.

The method may comprise, if it is determined that the candidate policyand charging rules node has not already been selected by a policy andcharging rules enforcement node to serve the mobile node, performing theselecting and determining steps again for one or more further candidatepolicy and charging rules node either until one is selected for which itis determined that it has already been selected by a policy and chargingrules enforcement node to serve the mobile node or until there are nofurther candidates to select.

The method may comprise, if no candidate policy and charging rules nodeis selected for which it is determined that it has already been selectedby a policy and charging rules enforcement node to serve the mobilenode, rejecting the request to register the mobile node to thesubsystem, at least in respect of the participating proxy node.

The method may comprise performing the steps again for a further proxynode.

According to a second aspect of the present invention there is providedan apparatus for use in registering a mobile node of atelecommunications network to a subsystem of the network, the networkhaving at least one node for maintaining or having access to policy andcharging rules for users of the network and at least one node forenforcement of the policy and charging rules to traffic flows, theapparatus comprising means for receiving a registration request messagefrom the mobile node, means for selecting a candidate policy andcharging rules node for the mobile node, means for determining whetherthe candidate policy and charging rules node has already been selectedby a policy and charging rules enforcement node to serve the mobilenode, and means for performing subsequent steps of the registrationprocedure in dependence on the determination.

According to a third aspect of the present invention there is provided amethod for use by an apparatus as part of a method of registering amobile node of a telecommunications network to a subsystem of thenetwork, the apparatus being one of at least one node of the network formaintaining or having access to policy and charging rules for users ofthe network and the network having at least one node for enforcement ofthe policy and charging rules to traffic flows, the method comprising,following receipt at a proxy node of the network of a registrationrequest message from the mobile node and the selection of the apparatusas a candidate policy and charging rules node for the mobile node,determining whether the candidate policy and charging rules node hasalready been selected by a policy and charging rules enforcement node toserve the mobile node, such that subsequent steps of the registrationprocedure can be performed in dependence on the determination.

According to a fourth aspect of the present invention there is providedan apparatus for use in a method of registering a mobile node of atelecommunications network to a subsystem of the network, the apparatusbeing one of at least one node for maintaining or having access topolicy and charging rules for users of the network and the networkhaving at least one node for enforcement of the policy and chargingrules to traffic flows, the apparatus comprising means for determining,following the receipt at a proxy node of the network of a registrationrequest message from the mobile node and the selection of the apparatusas a candidate policy and charging rules node for the mobile node,whether the candidate policy and charging rules node has already beenselected by a policy and charging rules enforcement node to serve themobile node, such that subsequent steps of the registration procedurecan be performed in dependence on the determination.

According to a fifth aspect of the present invention there is providedan operating program which, when run on an apparatus, causes theapparatus to carry out a method according to the first or third aspectof the present invention.

According to a sixth aspect of the present invention there is providedan operating program which, when loaded into an apparatus, causes theapparatus to become apparatus according to the second or fourth aspectof the present invention.

The operating program may be carried on a carrier medium. The carriermedium may be a transmission medium. The carrier medium may be a storagemedium.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1, discussed hereinbefore, is a schematic diagram illustratingparts of a UMTS network;

FIG. 2, also discussed hereinbefore, illustrates schematically theintegration of an IP Multimedia Subsystem into a 3G mobilecommunications system;

FIG. 3, also discussed hereinbefore, illustrates schematically thenetwork entities proposed to handle policy functionality in 3GPP Rel-7;

FIG. 4 schematically illustrates signalling flow according to anembodiment of the present invention in the case of successful IMSregistration; and

FIG. 5 schematically illustrates signalling flow according to anembodiment of the present invention in the case of unsuccessful IMSregistration.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present applicants have appreciated that above-described proposed3GPP Rel-7 Policy and Charging Control (PCC) architecture specificationsare missing aspects of redundancy to allow the entities implementing thepolicy control functions to pass responsibility over to alternativeentities either due to failure of such entities or loss of communicationbetween them.

The proposed specifications do not ensure that the P-CSCF discovered andselected for the UE to communicate with the IMS is the one able to actas an AF for the UE for the purposes of policy and charging control. Asa result, the UE may successfully register to the IMS, but may later beprevented from using the IMS services when it attempts to invoke aservice if the P-CSCF has selected a PCRF entity different from the PCRFentity serving the UE.

As a consequence of using an embodiment of the present invention, it isgenerally ensured, at the time the UE attempts to register to the IMS,that the P-CSCF is able to communicate with the correct PCRF entityserving the UE. This may be achieved by arranging for the P-CSCF tocheck with the selected PCRF that it is the correct one. The basicmechanism is for the P-CSCF that is discovered and selected by the UE todetermine, at the time the UE is registering to the IMS, whether thePCRF entity the P-CSCF selects for the UE is the one already serving theUE.

This concept will now be described in more detail with reference toFIGS. 4 and 5. FIG. 4 illustrates a UE 4, a Gateway (GW) 10, a P-CSCF12, and a PCRF 13-1, with the rest of the IMS being represented by thepart labelled 15. FIG. 5 shows many of the same parts as FIG. 4, exceptthat two different PCRFs 13-1 and 13-2 are shown, while the rest of theIMS 15 is not shown. The signalling flow shown in FIG. 4 is for use inillustrating a case where registration to the IMS is ultimatelysuccessful, while the signalling flow shown in FIG. 5 is for use inillustrating a case where registration to the IMS is ultimatelyunsuccessful.

Reference will now be made to FIG. 4 to describe an example ofsuccessful IMS registration according to an embodiment of the presentinvention.

-   Step 1 of FIG. 4

The UE 4 sends a bearer request for use by the IMS signalling.

-   Step 2 of FIG. 4

The GW 10 may allocate an IP address to the UE 4, if not alreadyallocated. The GW 10 selects one of the PCRF entities to serve the UE 4;in this example it selects the PCRF 13-1.

-   Step 3 of FIG. 4

The GW 10 sends an authorisation request to the PCRF 13-1, including theIP address of the UE 4.

-   Step 4 of FIG. 4

The PCRF 13-1 may create a state for the UE 4 and store its IP address,if not already created. The PCRF 13-1 authorises the bearer and itsusage for IMS signalling according to a pre-configured policy. The PCRF13-1 determines relevant PCC rules for the IMS signalling.

-   Step 5 of FIG. 4

The PCRF 13-1 sends a successful authorisation response with the PCCrules for the IMS signalling.

-   Step 6 of FIG. 4

The GW 10 sends a successful bearer response to the UE 4.

-   Step 7 of FIG. 4

The UE 4 discovers and selects the P-CSCF 12, and attempts to registerto the IMS by sending a registration request (SIP REGISTER message) tothe P-CSCF 12.

(Steps 1 to 7 of FIG. 4 are steps that can be carried out according topreviously-proposed mechanisms.)

-   Step 8 of FIG. 4

When the P-CSCF 12 receives the registration request, it identifies fromthe request the IP address of the UE 4 attempting to register. TheP-CSCF 12 selects one of the PCRF entities configured for the IPaddress, in this case the PCRF 13-1, and decides to check the validityof the selection.

(Selecting the PCRF entity at this point and deciding to check thevalidity of the selection has not been previously proposed.)

-   Step 9 of FIG. 4

The P-CSCF 12 sends a validation request to the selected PCRF 13-1including the IP address identified in Step 8 of FIG. 4. As differentimplementation options, the validation request may either initiate astand-alone transaction (unrelated to an AF session), or a new AFsession. When an AF session is used for the validation, the P-CSCF 12may create an association between this AF session and the IMSregistration and/or the IMS signalling flow in the user plane.

(This step has not been previously proposed.)

-   Step 10 of FIG. 4

The PCRF 13-1 checks if it is serving this IP address. In this example,the result is successful.

(This step has not been previously proposed.)

-   Step 11 of FIG. 4

The PCRF 13-1 sends a successful validation response to the P-CSCF 12.

(This step has not been previously proposed.)

Steps 12 to 14 of FIG. 4

Successful registration to the IMS is concluded according topreviously-proposed mechanisms.

Reference will now be made to FIG. 5 to describe an example ofunsuccessful IMS registration according to an embodiment of the presentinvention.

-   Steps 1 to 7 of FIG. 5

These steps are the same as Steps 1 to 7 of FIG. 4 described above.

-   Step 8 of FIG. 5

When the P-CSCF 12 receives the registration request, it identifies fromthe request the IP address of the UE 4 attempting to register. TheP-CSCF 12 selects one of the PCRF entities configured for the IPaddress, in this case the PCRF 13-2, and decides to check the validityof the selection.

(Selecting the PCRF entity at this point and deciding to check thevalidity of the selection has not been previously proposed.)

-   Step 9 of FIG. 5

The P-CSCF 12 sends a validation request to the selected PCRF 13-2including the IP address identified in Step 8 of FIG. 5. As differentimplementation options, the validation request may either initiate astand-alone transaction (unrelated to an AF session), or a new AFsession. When an AF session is used for the validation, the P-CSCF 12may create an association between this AF session and the IMSregistration and/or the IMS signalling flow in the user plane.

(This step has not been previously proposed.)

-   Step 10 of FIG. 5

The PCRF 13-2 checks if it is serving this IP address. In this example,the result is unsuccessful because the selected PCRF 13-2 is not servingthe UE 4.

(This step has not been previously proposed.)

-   Step 11 of FIG. 5

The PCRF 13-2 sends a failed validation response to the P-CSCF 12.

(This step has not been previously proposed.)

-   Step 12 of FIG. 5

Upon receipt of the failed validation response, the P-CSCF 12 may selectanother PCRF entity, if more than one is configured for the UE 4, andmay re-attempt the validation, performing Steps 9 to 12 of FIG. 5 againfor a different PCRF entity. This would continue until either asuccessful validation response is received (in which case Steps 12 to 14of FIG. 4 could be performed) or until it is determined that no morePCRF entities can be identified. In this particular example, the resultis unsuccessful.

(This step has not been previously proposed.)

-   Step 13 of FIG. 5

The P-CSCF 12 sends a failed registration response to the UE 4 as aresult of the failed validation.

(This step has not been previously proposed.)

-   Step 14 of FIG. 5

The UE 4 may select another P-CSCF entity and re-attempt registration tothe IMS.

One advantage of an embodiment of the present invention is the improvedregistration procedure, during which it is ensured that the policycontrol entities are correctly selected and addressed, avoidingotherwise possible IMS service rejections.

Another advantage is the possibility for the P-CSCF to be notified whenIMS signalling flow between the UE and the GW is adversely affected, andtherefore the possibility for the IMS to take appropriate actions insuch conditions. This advantage is related to the second optiondescribed above in connection with Step 9 of FIGS. 4 and 5, in which anAF session is created between the P-CSCF and the PCRF at IMSregistration. The IP flows authorised by the P-CSCF for this AF sessioncorrespond to the SIP signalling flows between the UE and the P-CSCF.This AF session will exist for the duration of the registration. Sincean AF session is also a framework for the PCRF to notify an AF (here,the P-CSCF) of the loss of the bearer that carries the authorised flows,this option opens up the possibility for the P-CSCF to know when its SIPsignalling flows are affected.

Although the above embodiments have been described in the context ofUMTS and IMS, it will be appreciated that the same scheme can beimplemented in a telecommunications network corresponding to UMTS havinga subsystem of the network corresponding to IMS to which a mobile nodewould require registration. In the same way that UMTS/IMS does, such anetwork would have at least one node for maintaining or having access topolicy and charging rules for users of the network (corresponding to thePCRFs as described above), at least one node for enforcement of thepolicy and charging rules to traffic flows (corresponding to the GWs asdescribed above), and at least one proxy node (corresponding to theP-CSCFs as described above). The method would generally comprisereceiving a registration request message from the mobile node at a proxynode of the network, selecting a candidate policy and charging rulesnode for the mobile node, determining whether the candidate policy andcharging rules node has already been selected by a policy and chargingrules enforcement node to serve the mobile node, and performingsubsequent steps of the registration procedure in dependence on thedetermination.

It will be appreciated that operation of one or more of theabove-described components can be controlled by a program operating onthe device or apparatus. Such an operating program can be stored on acomputer-readable medium, or could, for example, be embodied in a signalsuch as a downloadable data signal provided from an Internet website.The appended claims are to be interpreted as covering an operatingprogram by itself, or as a record on a carrier, or as a signal, or inany other form.

1. A method of registering a mobile node of a telecommunications network to a subsystem of the network, the network having a plurality of policy and charging rules function (PCRF) nodes for maintaining or having access to policy and charging rules for users of the network, a node for enforcement of the policy and charging rules to traffic flows, and a session management node, the method comprising the steps of: receiving a registration request message from the mobile node at a proxy node of the network; selecting from the plurality of PCRF nodes, a candidate PCRF node for the mobile node; determining whether the candidate PCRF node has already been selected by the policy and charging rules enforcement node to serve the mobile node; and upon determining that the candidate PCRF node has already been selected by the policy and charging rules enforcement node to serve the mobile node, forwarding the registration request from the proxy node to the session management node to complete the registration of the mobile node to the subsystem of the network.
 2. The method as claimed in claim 1, wherein the network is a Universal Mobile Telecommunications System network.
 3. The method as claimed in claim 2, wherein the mobile node is a User Equipment of the Universal Mobile Telecommunications System.
 4. The method as claimed in claim 2, wherein each PCRF node includes a Policy and Charging Rules Function of the Universal Mobile Telecommunications System.
 5. The method as claimed in claim 2, wherein the policy and charging rules enforcement node comprises a Gateway Node of the Universal Mobile Telecommunications System.
 6. The method as claimed in claim 2, wherein the proxy node comprises an Application Function of the Universal Mobile Telecommunications System.
 7. The method as claimed in claim 2, wherein the proxy node comprises a Proxy Call Session Control Function of the Universal Mobile Telecommunications System.
 8. The method as claimed in claim 2, wherein the subsystem is an IP Multimedia Subsystem.
 9. The method as claimed in claim 1, wherein the determining step comprises the steps of: sending a validation request from the proxy node to the candidate PCRF node, said validation request including information for use by the candidate PCRF node for determining whether the candidate PCRF node has already been selected by the policy and charging rules enforcement node to serve the mobile node, and basing the determination on a reply received from the candidate PCRF node.
 10. The method as claimed in claim 9, wherein the validation request is sent as part of an Application Function session between the proxy node and the candidate PCRF node.
 11. The method as claimed in claim 9, wherein the information comprises an IP address of the mobile node.
 12. The method as claimed in claim 11, comprising checking whether the IP address of the mobile node is already stored in the candidate PCRF node.
 13. The method as claimed in claim 1, wherein when it is determined that the candidate PCRF node has not already been selected by the policy and charging rules enforcement node to serve the mobile node, the method repeats the selecting and determining steps for one or more further candidate PCRF nodes from the plurality of PCRF nodes until either one candidate PCRF node is selected that has already been selected by the policy and charging rules enforcement node to serve the mobile node, or until there are no further candidate PCRF nodes to select from the plurality of PCRF nodes.
 14. The method as claimed in claim 13, wherein if no candidate PCRF node is selected that has already been selected by the policy and charging rules enforcement node to serve the mobile node, the method includes rejecting the request to register the mobile node to the subsystem.
 15. The method as claimed in claim 14, further comprising repeating the selecting and determining steps for a further proxy node.
 16. An apparatus for use in registering a mobile node of a telecommunications network to a subsystem of the network, the network having a plurality of policy and charging rules function (PCRF) nodes for maintaining or having access to policy and charging rules for users of the network, a node for enforcement of the policy and charging rules to traffic flows, and a session management node, the apparatus comprising: means for receiving a registration request message from the mobile node; means for selecting from the plurality of PCRF nodes, a candidate PCRF node for the mobile node; means for determining whether the candidate PCRF node has already been selected by the policy and charging rules enforcement node to serve the mobile node; and means for forwarding the registration request from a proxy node to the session management node to complete the registration of the mobile node to the subsystem of the network in response to determining that the candidate PCRF node has already been selected by the policy and charging rules enforcement node to serve the mobile node.
 17. A method of selecting a policy and charging rules function (PCRF) node from a plurality of PCRF nodes for providing policy and charging rules for users of a telecommunications network as part of a process of registering a mobile node of the telecommunications network to a subsystem of the network, the network having a proxy node and a node for enforcement of the policy and charging rules to traffic flows, the method comprising the steps of: receiving at the proxy node of the network, a registration request message from the mobile node; selecting from the plurality of PCRF nodes, a candidate PCRF node for the mobile node; continuing the registration of the mobile node when the candidate PCRF node has already been selected by the policy and charging rules enforcement node to serve the mobile node; and when it is determined that the candidate PCRF node has not already been selected by the policy and charging rules enforcement node to serve the mobile node, repeating the selecting and determining steps for one or more further candidate PCRF nodes from the plurality of PCRF nodes until either one candidate PCRF node is selected and for which it is determined that the selected candidate PCRF node has already been selected by the policy and charging rules enforcement node to serve the mobile node or until there are no further candidate PCRF nodes to select from the plurality of PCRF nodes; and rejecting the registration request when there are no further candidate PCRF nodes to select from the plurality of PCRF nodes.
 18. An apparatus in a policy and charging rules function (PCRF) node for providing policy and charging rules for users of a telecommunications network having a gateway node, a proxy node, and a session management node, said apparatus being utilized in a process of registering a mobile node of the telecommunications network to a subsystem of the network, the apparatus comprising: means for receiving an authorization request from the gateway node, said authorization request including an identifier of the mobile node and a request for the PCRF node to serve the mobile node; means for storing the identifier of the mobile node when the authorization request is received from the gateway node; means for receiving a validation request from the proxy node of the network, said validation request including the identifier of the mobile node and querying whether the PCRF node has been requested by the gateway node to serve the mobile node; means for determining whether the apparatus has stored the identifier for the mobile node; and means for sending a response to the proxy node indicating that the PCRF node has been requested by the gateway node to serve the mobile node when the apparatus has stored the identifier for the mobile node, and for sending a response to the proxy node indicating that the PCRF node has not been requested by the gateway node to serve the mobile node when the apparatus has not stored the identifier for the mobile node; wherein the proxy node is configured to send a registration request to the session management node to register the mobile node to the subsystem of the network when the response from the PCRF node indicates that the PCRF node has been requested by the gateway node to serve the mobile node.
 19. A non-transitory computer program loaded onto an internal memory of a proxy node of a telecommunications network having a plurality of policy and charging rules function (PCRF) nodes for maintaining or having access to policy and charging rules for users of the network, and a node for enforcement of the policy and charging rules to traffic flows, the computer program comprising software code portions for causing the proxy node to perform the following steps when the computer program is run on a processor of the proxy node: receiving a registration request message from a mobile node; selecting from the plurality of PCRF nodes, a candidate PCRF node for the mobile node; determining whether the candidate PCRF node has already been selected by the policy and charging rules enforcement node to serve the mobile node; continuing a registration procedure for the mobile node when the candidate PCRF node has already been selected by the policy and charging rules enforcement node to serve the mobile node; and when the candidate PCRF node has not been selected by the policy and charging rules enforcement node to serve the mobile node, repeating the selecting and determining steps for further candidate PCRF nodes from the plurality of PCRF nodes until either the proxy node selects a candidate PCRF node that has already been selected by the policy and charging rules enforcement node to serve the mobile node, or until there are no further candidate PCRF nodes to select from the plurality of PCRF nodes. 